Magnum One/Magnum One (Mid-American Digital) (Disc Manufacturing).iso/d2/popup.arc/POPUP.DOC

Text File | 1988-05-29 | 10.2 KB | 212 lines

The following is a summary of a talk given by Bob Bierman of Living
Videotext. Bob is the chief programmer for READY, a memory-resident
outline processor. The talk was given on 2/11/86 at the IBM Special
Interest Group of te Software Entrepreneur's Forum in the San
Francisco Bay Area. Bob described many of the techniques used to
develop a "machine-friendly" memory-resident program. Any confusion
in the following is due to the summarizer, and not based on any
problem of Bob's.

READY takes several steps beyond those of earlier memory-resident
programs (TSRs). Perhaps most importantly, it allows the bulk of the
TSR to reside in expanded memory (LIM EMS). A single version of READY
self-configures to use EMS or not depending on its presence in the
system. When EMS is used, the kernel of the TSR in normal memory
uses only 4K bytes. The rest of the code and data in expanded memory
use about 175K bytes.

When the READY hot key is pressed, the first step is to determine
whether it is safe to interrupt DOS or the application at that time.
We will return to this important issue below. Assuming it is safe,
READY remaps the EMS page window to access one section of the EMS
code. Control is transferred to the EMS page window. Then a 16K page
window is used to swap whatever is in the top 160K bytes of normal
memory into EMS, while pulling the rest of READY's code and data
into the normal memory formally owned by the swapped area. Control
is then transferred into normal memory and READY executes from there.

The swapping process takes about 1 second on a PC, and negligible
time on an AT. This swap time is apparently not bothersome to the
users of READY, who are most happy to get their normal memory back.

The swap of READY's code is made into high memory of the PC to
hopefully avoid overwriting other memory-resident programs at the
lower end of memory. This would be disasterous since a hot-key
interrupt for those other programs would jump into READY's code
at some undetermined point. READY checks other interrupts at
invocation to help avoid this possibility.

The choice of the full swap from EMS to normal memory was not
made lightly, according to Bob. The full swap was the weakest of
several possibilities considered, but it had the advantage of working
on schedule. The swap approach is also the least likely to cause
problems when other TSRs take advantage of EMS. Bob pointed
out three additional difficulties with executing directly from
expanded memory -- if the code and data are larger than the 64K
window of EMS, the program needs to have a well defined overlay
structure allowing 16K chunks to be pulled in and out of the EMS
page window; the disk transfer area (DTA) used by the TSR cannot
reside in the EMS page window when an EMS RAMdisk is in use; the
stack of the TSR should not reside in EMS due to some stack
swapping problems when EMS functions are called.

READY also breaks new ground in the way it deinstalls itself.
Many TSRs will deinstall whenever the user asks for it. This
may leave holes in DOS' memory allocation structure, leading
to problems. READY will not deinstall itself until it senses
that all memory above itself is free. When the user requests
deinstallation, READY sets a flag and then awaits the
appropriate time for deinstallation. EMS memory is freed up
immediately after the request is made.

The trickiest portion of writing the TSR is determining when
DOS or the application is interruptable. DOS provides no clean
services to make this determination. Bob recommends checking
several different monitors before allowing the "pop-up"
to occur.

The first step in popping up is detecting the application's
hot key. In READY, INT 9 is used because they also want to
detect some of the keystrokes (like Ctrl-ArrowUp) that the BIOS
doesn't report. When the hotkey is detected by INT 9, a flag
inside READY is set, but READY is not activated.

DOS provides two hooks that should normally allow safe popups.
INT 21 function 34 returns a pointer to the InDOS flag in ES:BX.
If the byte pointed to is 0, DOS is not active and therefore any
DOS call can be safely made. However, function 34 itself cannot
be called at any time. This function does a stack switch before
returning its result, and apparently due to an oversight of its
programmer, it does the stack switch with interrupts enabled.
This opens the possibility for function 34 to mess itself up
if it is called at the wrong time.

Bob also noted that the InDOS flag is not simply a binary value.
It represents a count of "recursions" into DOS.

DOS can also be interrupted at certain times even when the InDOS
flag is not 0. While DOS is waiting for keyboard input, the InDOS
flag is set to (usually) 1, but at the same time, DOS also
continually calls INT 28. Apparently, INT 28 was created
specifically to allow the DOS PRINT command to run in the
background. In any case, if the TSR watches for INT 28 calls, it
is safe to use any DOS function above 9 during the INT 28.

Other monitors must also be checked before invocation.
Because many programs use the BIOS calls without going through
DOS, it is necessary to check whether the BIOS disk calls (at
least) are active. This is done simply by taking over the disk
interrupt (INT 13), and setting a flag (within READY's data
area) upon entry to the interrupt, and resetting it upon exit
from the interrupt. Before popping up based on some other
interrupt, READY checks its own "InINT13" flag to make sure that
no disk access is in progress. READY follows the same scheme
for several other interrupts.

Looking at the DOS memory map after installing READY, it becomes
apparent that all of the following vectors are taken over by
the program.

  8  Timer
  9  Hardware Keyboard
  10 Video
  13 Diskette
  16 BIOS Keyboard
  20 Program Terminate
  21 DOS
  25 Absolute Disk Read
  26 Absolute Disk Write
  27 TSR
  28 Background Process

In all likelihood 8, 13, 21, 25, 26, and 28 are taken over
specifically to allow safe popups without disturbing the system.
INT 16 is used by READY's "key transfer" scheme to pass
keystrokes in to DOS or an application (like the cut and paste
of SuperKey and SideKick). INT 9 is used to supply special keystrokes
and to aid in the pop up process. INT 10 is used to keep
track of the video mode of the system (READY turns off the hardware
cursor and maintains its own flashing reverse video block).
INT 20 and INT 27 are most likely used to aid in the
deinstallation process.

This author's guess of the overall popup scheme is as follows:

  INT 9 is used to set a flag that the hotkey (Ctrl-Keypad 5) has
  been pressed or released.

  On each timer tick, the hotkey flag is checked. If set, the
  READY-maintained inINTxx flags are checked for safeness. If
  the INT 21 flag is set or if another "dangerous" BIOS or DOS
  interrupt is active, activation does not occur at the
  timer tick.

  On each INT 28 call, the hotkey flag is checked. If set,
  DOS function 34 is also checked to be not greater than 1.

Without actually implementing this, it is a bit hazy but
hopefully gets the idea across.

Bob emphasized that while "deinvoking" the popup it is just as
critical that the safeness flags be monitored as while invoking it.

READY keeps no files opened between invocations. Files are
opened only when an outline is read or written from memory, and
then immediately closed. If all DOS handles are in use, READY
will not be able to access the disk.

READY fully chains all interrupts that it takes over. This means
that all interrupt handlers installed before and after it get
their chance at the interrupt. Bob recommended that for chaining
INT 16, the chaining process use the INT instruction rather than
a CALL FAR instruction. By using INT rather than CALL FAR, handlers
installed AFTER READY get another chance at the interrupt. This
obviously requires that some flags be set inside READY to avoid
an infinite recursion, and it is not necessary for most of the
interrupts. It is particularly important, however, for INT 16
(keyboard), where macro processors may need to be invoked. It
also plays a role in the delaying mechanisms used when passing
keystrokes into other applications.

READY does not take any special pains to work with programs
(such as XYwrite) which take over the keyboard without chaining.
Bob believes that any tricks to make these work will cause more
problems than they solve. In particular, the SideKick trick
of "stealing back" the hardware keyboard interrupt on each
timer tick would be a disaster if other programs attempted
to do the same thing. Living Videotext is working with other
publishers to get their programs cleaned up and compatible
in this sense. They are also trying to set a standard for the
scan codes returned for keystrokes not supported by the BIOS.

A few general pointers: according to Bob, the "memory-resident
interface code" of READY amounts to 12,000 lines of assembly
language. Writing a bulletproof and machine friendly TSR is
obviously no job for the weekend hacker! The rest of READY is
written in Pascal (probably Microsoft, but definitely a linked
version of Pascal). READY includes its own "relocator" which
fixes up the EXE image of the program when it is relocated
from EMS to normal memory.

The resident portion of READY could not have been developed
on schedule without the ATRON hardware debugger, said Bob.
This $1500 piece of hardware allows you to continue from
hard crashes, and to investigate the state of the machine
to determine what happened. If you can't afford this, at least
get an NMI reset card. The "AT Technical Reference - Options
and Adapters" is an invaluable guide that many developers
do not have.

The PC Network is a disaster for memory-resident programs.
It takes over interrupts in a very unfriendly way, and
READY will not work with it.

A number of the major vendors of TSRs are currently meeting
informally to reach some agreement on behavioral standards
for TSRs. Watch for some announcements this year. Microsoft
is decidedly against TSRs, and as versions of DOS roll by,
support for TSRs (such as it is) will wane while support
for true multitasking will improve.

summarized by Kim Kokkonen